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1.   INTRODUCTION 

The  purpose  of  this  thesis  is  to  lay  the  theoretical  background  for 
the  addition  of  new  array  types  to  the  01/2  language.  The  next  section  con- 
cerns itself  with  data  structures  for  describing,  and  with  algorithms  for 
partitioning  ,  Hessenburg  arrays  and  their  subarrays.  The  current  language 
structure  is  adequate  to  handle  this  addition.  It  is  not  adequate,  however, 
to  handle  band  arrays  and  their  subarrays,  the  subject  of  section  3.  Investi- 
gations are  made  to  find  what  additional  information  is  necessary  for  de- 
scribing these  arrays  and  new  data  structures  are  proposed.  New  algorithms 
for  partitioning  are  also  derived.  Finally,  a  rotate  operator,  which  can 
generate  new  array  types  from  the  existing  ones,  is  proposed  and  suggested 
implementations  are  given. 

The  design  philosophy  and  present  state  of  the  01/2  language  are 
given  in  the  references  [1,2,3]. 


2.   HESSENBURG  FORM 

2.1  OI/2  Background 

Arrays  in  OL/2  are  stored  sequentially  in  row  major  order.  Only 
those  elements  which  are  not  theoretically  zero  are  retained.  Elements  of  an 
array  are  accessed  by  means  of  control  information  kept  in  the  array  control 
block,  (ACB) ,  corresponding  to  that  array  [2,3].  See  Figure  1. 

Of  greatest  importance  in  locating  elements  of  an  array  are  the  co, 
6R,  and  6D  fields.  The  value  of  w  specifies  the  location  of  the  first  acces- 
sible element  in  that  array.  The  value  of  6D  is  defined  as  the  number  of 
accessible  elements  in  row  i+1  minus  the  number  of  accessible  elements  in  row 
i.  For  each  array  type  this  value  is  constant  for  all  i.  The  following  equa- 
tion serves  to  define  8R: 

6R  =  L0C(A(2,j))  -IOC(A(l,j)) 

for  any  j  provided  both  A(2,j)  and  A(l,j)  are  stored  elements.  For  diagonal 
and  strictly  lower  triangular  arrays,  6R  is  defined  to  be  zero. 

The  location  of  an  arbitrary  array  element  can  be  found  by: 

LOC(A(i+6i,j+6j))  =  us  +  5R(i) 6i  +  6D(6i(6i-l) )/2  +  6j 

where  w  =  L0C(A(i,j) ) ,  6R(i)  =  6R  +  (i-1) 6D,  and  (i,j)  e  { (1,1) , (1,2) , (2,1) } 
depending  on  the  array  type. 

When  an  array  is  partitioned,  the  p  field  of  the  ACB  of  that  array 
is  set  to  point  at  a  partition  control  block,  (PCB) .  See  Figure  2.  The  PCB 
contains  information  on  how  the  array  is  partitioned  and  how  the  contents  of 
the  ACBs  of  the  subarrays  are  to  be  filled  in. 

2.2  Upper  and  Lower  Hessenburg  Arrays 

An  Tipper  Hessenburg  array,    (UH) ,  may  be  described  as  an  n*n  array 


n 
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6D 

*1 
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P 

where   n  -  name  of  array 
A  -  dimensionality 
x  -  geometric  type 
co  -  origin 
&R  -  row  increment 
6D  -  diagonal  increment 

A.  -  lower  bounds 
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y.  -  upper  bounds 

p  -  partition  pointer 


Figure  1.  Array  control  block 
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Figure  2.  Partition  control  block 


where  the  subscripts  of  the  theoretically  non-zero  elements  satisfy  the  rela- 
tion: 

-(n-1)  <_  i-j  <_  1  for  1  <_  i/j  <_  n. 

For  a  Lower  Hessenburg  array,  (LH) ,  the  relation  is 

-(n-1)  <_  j-i  <_  1  for  1  <_  i,  j  <^  n. 

The  number  of  non-zero  elements  in  either  array  is  (n(n+3)-2)/2. 

The  ACBs  which  describe  Hessenburg  arrays  follow  the  same  format  as 
ACBs  for  other  arrays  in  OL/2.  The  6R,  6D,  and  oj  fields  for  upper  Hessenburg 
arrays  are  n,  -1,  and  1,  respectively,  where  n  is  the  order  of  the  array.  The 
corresponding  ACB  fields  for  a  lower  Hessenburg  array  are  2,  1,  and  1.  See 
Figure  3. 

2.3  Partitioning  of  Hessenburg  Arrays 

Following  the  convention  of  triangular  array  partitioning,  the  parti- 
tioning of  Hessenburg  arrays  is  restricted  to  simultaneous  identical  row  and 
column  partition  lines.  Such  partitioning  yields  the  new  array  types  upper 
right  corner,  (URC) ,  and  lower  left  corner,  (LLC) .  See  Figure  4.  The  types 
of  the  subarrays  for  arbitrary  number  of  partition  lines  are  given  in  the  fol- 
lowing table: 

subarray  type 

A<i,i>        same  as  parent 

A<i,j>        RECT  for  j>i  and  UH  parent 

j<i  and  LH  parent 

A<i,j>        URC   for  i=j+l  and  UH  parent 
LLC   for  j=i+l  and  LH  parent 

other        null 


12   3   4  5 

6   7   8   9  10 

11   12  13  14 

15  16  17 

18  19 


Upper  Hessenburg  order  (5) 


1  2 

3  4  5 

6  7  8   9 

10  11  12  13  14 

15  16  17  18  19 
1 1 


Lower  Hessenburg  order  (5) 


ACB    |  |  | 

|    n  =  name  |    A  =  2         | 

1 1 1 

I  I  I 

|     t  =  UH       |     <SRf  5  | 

1 1__ 1 

1  '  «        • 

|     u»  -  1  |     6D=  -1        | 

1 1 1 

I  I  I 

I    M«  1        I    »«f  5        I 

1 1 1 

I  I  I 

I     X2=  1          |     y2=  5         | 
1 1 1 

I  I 

|  p  =  null  | 

1 1 

|     n  =  naraej     A  =  2        | 

1 1 1 

I  !  I 

|      T  =  LH      |      6R=  2        | 

1 1 1 

1  '  «         ' 

|      co  =   1         |      6D=   1  | 

1 1 i 

I                          I  I 

I      Xi=   1         I      Ml=  5         | 
1 1 1 

I  I  I 

|     x2=  1       I     y2=  5       I 

1 1 1 

I  I 

|  p  =  null  | 

1 1 


Figure  3.  Hessenburg  arrays  and  corresponding  ACBs 
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Figure  4.  Partitioning  of  Hessenburg  arrays 


Figure  5.  Partitioning  of  a  tridiagonal  array 
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The  ACB  control  information  for  the  non-corner  subarrays  is  gener- 
ated in  the  same  manner  as  that  generated  for  the  existing  array  types.  This 
includes  use  of  the  following  formula  for  origin  calculation: 


LOC(A(i+6i/j+6j))  =  to  +  6R(i)6i  +  6D(6i(6i-l)  )/2  + 


6j 


where  w  =  L0C(A(1,1))  and  i=j=l.  The  values  of  <5D  and  6R  are  copied  from  the 
corresponding  fields  in  the  parent  array  ACB.  The  subarray  bounds  are  calcu- 
lated from  the  parent  array  bounds  and  the  partition  lines  in  the  usual  manner. 

The  generation  of  the  ACBs  for  the  corner  type  arrays  is  easy  be- 
cause of  the  special  form  of  the  arrays.  Due  to  the  fact  that  a  corner  array 
consists  of  only  one  accessible  element,  the  6R  and  6D  fields  are  not  needed 
and  are  set  to  zero.  The  origin  field,  co,  calculated  by  the  above  formula, 
points  to  this  only  non-zero  element.  The  coordinates  of  this  element  with 
respect  to  the  parent  array  are  (q+l,q)  for  URC  and  (p,p+l)  for  LLC,  where  p 
is  the  partition  line  which  bounds  the  array  on  the  left  (or  bottom)  ,  and  q  is 
the  partition  line  which  bounds  the  array  on  the  right  (or  top)  .  The  bounds, 
again,  are  a  simple  function  of  the  parent  array  size  and  the  partition  lines. 

The  partitioning  of  subarrays  of  Hessenburg  type  is  identical  to  the 
partitioning  of  the  original  Hessenburg  array.  The  arbitrary  partitioning  of 
a  corner  array  yields  a  corner  subarray  of  the  same  type  and  various  null  sub- 
arrays. 

The  introduction  of  URC  and  LLC  arrays  is  of  importance  in  the  parti- 
tioning of  the  existing  tridiagonal  type  array.  With  this  type,  partitioning 
is  also  restricted  to  simultaneous  row  and  column  partition  lines.  In  the 
case  of  one  row  and.  column  partition  line,  the  subarrays  consist  of  two  tri- 
diagonal and  one  each  of  URC  and  LLC  type.  See  Figure  5.  In  the  past,  the 
element  in  each  of  the  corner  arrays  was  unaccessible  except  by  explicit 


element  subscripting,  i.e.,  A(p+].,p)  or  A(p,p+1)  .  With  the  implementation  of 
the  corner  arrays,  this  unwanted  restriction  can  be  lifted. 

2.4  Compiler  Tables  for  Arithmetic  and  "Part  of"  Operations 

The  addition  of  the  new  array  types,  UH,  LH,  UPC,  and  LLC  more  than 
double  the  size  of  the  tables  used  to  determine  the  array  type  of  the  sum  or 
product  of  two  matrices.  See  Figures  6  and  7.  Of  importance,  though,  are  the 
starred  entries  in  which  the  new  array  types  allow  more  efficient  use  of  stor- 
age in  those  cases  where  the  result  is  of  Hessenburg  type.  Because  this  array 
type  was  not  available  previously,  a  rectangular  array  type  had  to  be  used. 

A  feature  of  OL/2  allows  the  user  to  take  a  'part  of  an  array,  such 
as  the  upper  triangular  part  of  a  square  array.  The  it  field  of  the  PCB  of  the 
parent  array,  P,  is  used  to  point  at  the  ACB  of  the  'part  of  subarray,  S,  as 
shown  in  Figure  8.  With  the  addition  of  Hessenburg  array  types,  one  must  allow 
the  user  to  take  the  'part  of  a  Hessenburg  array,  and  to  take  the  upper  or 
lower  Hessenburg  'part  of  other  arrays  under  the  existing  limitation  that  all 
of  the  elements  of  the  subarray  must  be  accessible  elements  of  the  parent  array. 
The  rules  for  generating  the  bounds  and  origin  control  information  of  the  sub- 
array  ACB  are  given  in  Figure  9.  The  <SR  and  <5D  fields  are  copied  from  the 
corresponding  fields  in  the  parent  array  ACB. 


10 


+ 
URC 
LLC 
LH 
UH 
SLT 
LT 
ID 
D 
UT 
SOT 
R 


|      URC     LLC     LH       UH       SLT     LT       TD       D 
f 

URC     R  R         UH       R 


UT  SOT  R 

UT  SOT  R 

R  R  R 

R  R  R 

UH  UH  R 

R  R  R 

R  R  R 

UH*  UH*  R 

UT  UT  R 

UT  UT  R 

UT  SOT  R 

R  R  R 


R         UH       UT 
LT       LH       LT 


R 


LH       LH 


LH       LH       LH       LH 


UHR  R  UHR  R  UH  UH 

R  SLT  LH  R  SLT  LT  LH*  LT 

R  LT  LH  R  LT  LT  LH*  LT 

UH  LH  LH  UH  LH*  LH*  TD  TD 

UT  LT  LH  UH  LT  LT  TD  D 

UT  R  R  UH  R  R  UH*  UT 

SOT  R  R  UH  R  R  UH*  UT 


R  R         R  R 


R         R 


Figure  6.  Geometric  type  of  sum  of  two  matrices 
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Figure  7.  Geometric  type  of  product  of  two  matrices 
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Figure  8.  Data  structure  for  UT  part  of  rectangular  array 
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Figure  9.  Rules  for  calculating  y  .  (S)  and  w  (S) 
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3.  BAND  FORM 

3.1  Representation  of  Band  Arrays 

A  band  array  may  be  described  as  an  n><n  array  in  which  the  subscripts 
of  the  theoretically  non-zero  elements  satisfy  the  relation: 

|i-j|  <_  w-1  for  1  <_  i,j  <_  n, 

where  w  is  the  width  of  the  array,  i.e.,  the  number  of  non-zero  elements  in  the 
first  row.  See  Figure  10.  Ihe  number  of  non-zero  elements  is  w(2n-w+l)-n. 

Other  array  types  in  OL/2  have  a  constant  6D,  i.e.,  a  constant  in- 
crease or  decrease  in  the  number  of  elements  in  adjacent  rows.  This  constant 
is  known  at  compile  time  from  the  array  type.  Band  arrays,  on  the  other  hand, 
do  not  have  this  property.  The  values  of  6R(i)  for  row  i,  1  <_  i  <_  (n-1)  ,  go 
through  the  values: 


w,  w+1,  ...,  w+a,  w+a,  ...,  w+a,  w+a-1,  ...,  w 

where  both  a  and  b  are  functions  of  the  order  and  width  of  the  array: 

a  =  max  (min  (n-w,w-2)  ,  0)  for  w  >_  2 
b  =  max  (n-2w+3 ,  2w-n-l)   for  w  >_  2  . 

Clearly,  the  present  01/2  ACB  structure  is  not  sufficient  to  describe  band 
arrays.  How  can  band  arrays  be  described?  What  ACB  information  is  necessary? 
The  answers  to  these  questions  are  the  goal  of  the  following  discussion. 

Band  arrays  consist  of  three  subarrays  in  each  of  which  6D  is  con- 
stant. Let  us  define: 

a  =  min(w,n-w) 
6  =  max(w,n^w) 
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Figure  10.  Band  array 
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then 

5D=1  for  1  <_  row  <_  a 
6D=0  for  a  <  row  <_  $ 
6D=-1  for  6  <  row  <  n. 

See  Figure  11.  Given  the  row  value,  6D  is  known,  and  therefore  6R(i)  is  known. 
See  Figure  12.  Care  must  be  taken,  however,  when  crossing  over  from  one  sub- 
array  to  another,  and  in  the  special  cases  when  w=l  and  w=n. 

Of  interest  are  the  number  of  theoretically  non-zero  elements  in  each 
of  these  subarrays  defined  by  6D.  Let  Tl  be  the  subarray  in  which  6D=1,  T2 
where  6D=0,  T3  where  6D=-1.  Let  N(Ti)  denote  the  number  of  elements  in  Ti. 
Then 

N(T1)  =  a(a+2w-l)/2 
N(T2)  =  (n-2a)min(2w-l,n) 
N(T3)  =  N(T1)  by  symmetry. 

Of  fundamental  importance  is  the  answer  to  the  question,  "Given  a 
band  array  of  order  n  and  width  w,  what  is  the  sequential  storage  location  of 
A(i,j)?"  First,  it  must  be  determined  whether  A(i,j)  is  a  stored  element.  The 
subscripts  of  stored  elements  satisfy  the  relation: 

|i-j|  £  (w-1)  for  1  <_  i,j  <_  n  . 

Let  us  assume  that  A(i,j)  is  a  stored  element.  Then  the  location  of  A(i,j)  is 
given  by  one  of  the  following  formulas  depending  on  the  value  of  i: 
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Case  1.  w  <  n  -  w      _1 

6D=1 

6D=0 

6D=-1 


Case  2.  w  >  n  -  w 


6D=1 


6D=0 


6D=-1 


n  -  w 


n  -  w 


Case  3.  w  =  n  -  w      _  l_____w 1 n_-_w 1  _ 


6D=1 


6D=-1 


n  -  w 


Figure  11.  Subarrays  of  band  array  defined  by  6D 
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for  1  <  i  <  a  (when  w=n,  no  i  will  satisfy  this  relation) , 

LOC(A(i,j))  =  L0C(A(1,1))  +  (i-1) (i+2w-2)/2  +  j  -  1 
for  a  <  i  £  3  (when  w=n-w,  no  i  will  satisfy  this  relation) , 
LOC(A(i/j))  =LX(A(1,1))  +  N(T1)  +  (i-a-1)  (min(2w-l,n) )  + 
j  "  * 
where        x=l  for  a=n-w,  and  x=i-a+l  for  a=w 

for  6  <  i  <  n  (when  w=n,  no  i  will  satisfy  this  relation) , 
LOC(A(i,j))  =  L0C(A(1,1))  +  N(T1)  +  N(T2)  + 

(i-B-D  (min(2w-l,n-l))  -  (i-3-2)  (i-3-l)/2  + 
j  -  i  +  w  -  1 

where         L0C(A(1,1))  =  1  for  the  original  array. 

Let  us  now  assume  that  A(i,j)  is  not  a  stored  element.  Then  it  is 
necessary  for  partitioning,  as  shown  later,  to  find  the  smallest  value  of  i' 
(or  j1)  for  which  A(i',j)  (or  A(i,j'))  is  stored.  There  are  twD  cases  (Figure 
13): 

for  i-j  >  (w-1) 

1  <_  i  <_  a  -  not  possible 

a  <  i  <_  6  ^ 

\       j'  =  i  -  w  +  1 

6  <  i  <_  n  J 
for  i-j  <  -(w-1) 

1  <_  i  <_  a  \ 

i'  =  j  -  w  +  1 

a  <  i  <_  3  J 

3  <  i  £  n  -  not  possible. 

The  sequential  location  of  the  stored  element  A(i',j)  (or  A(i,j'))  can  now  be 
found  by  the  previous  formulas. 
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A(i.j) 


A(i.j) 


Case  2.  i-j<-(w-1) 


Figure  13.  Finding  the  nearest  stored  element  in  the  same  row  or  column 
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The  previous  discussion  has  exenplif ied  the  dependence  of  the  repre- 
sentation of  band  arrays  on  n  and  w.  Partitioning,  as  will  again  be  shown, 
requires  knowledge  of  absolute  subscripts.  From  these  considerations,  the  ACB 
structure  for  band  arrays  is  proposed.  See  Figure  14.  The  r\,   A,  t,  w,  A.,  y., 

and  p  fields  have  the  same  interpretation  as  the  corresponding  fields  in  ex- 
isting ACBs.  In  place  of  the  6R  and  6D  fields  are  the  w,  s,  n1,  and  w'  fields. 
The  w  field,  along  with  a  y.  field,  describe  the  size  and  shape  of  the  array. 

The  s,  n1,  and  w1  fields  describe  the  location  of  this  array  with  respect  to 
the  original  parent  array  (which  may  be  itself)  for  the  purpose  of  determining 
how  6D  varies  in  this  array.  All  of  this  ACB  information  for  the  original 
array  is  available  from  the  array  declaration. 

3.2  Partitioning  of  Band  Arrays 

The  partitioning  of  band  arrays  is  restricted,  as  is  that  for  other 
non-rectangular  arrays,  to  simultaneous  identical  row  and  column  partition 
lines.  Such  partitioning  gives  rise  to  subarrays  of  three  major  types:  band, 
null,  and  a  new  type,  DB  (diagonally  bounded  array) . 

An  upper  (or  lower)  EB  array  may  be  described  as  an  nxm  array  in 
which  all  of  the  theoretically  non-zero  elements  lie  above  (or  below)  one  of 
n+m  diagonal  lines.  Being  a  subarray  of  a  band  array,  DB  arrays  inherit  the 
problems  of  ACB  representation,  6D  and  6R,  and  origin  calculation.  Luckily, 
most  of  the  information  about  band  arrays  can  be  carried  over.  The  ACB  struc- 
ture for  DB  arrays  is  given  in  Figure  15.  The  format  of  the  ACB  is  the  same 
as  that  for  band  arrays  with  only  slightly  different  interpretation.  The  n, 
A,  t,  to,  X.,  y.,  and  p  fields  serve  their  same  purposes.  The  w  and  y.  fields 

describe  the  size  and  shape  of  the  array.  Here,  though,  w  is  not  the  width 
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n 

-  name  of  array 
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-  dimensionality 
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-  geometric  type 

CD 
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A. 
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-  lower  bounds 
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-  upper  bounds 
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-  width 
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-  (i,j)  coordinates  of  upper  left  corner 

n' 

-  order  of  oldest  ancestor 

w' 

-  width  of  oldest  ancestor 

P 

-  partition  pointer 

Figure  14.  ACB  for  band  arrays 
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A  -  dimensionality 

t  -  geometric  type 
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Figure  15.  ACB  for  diagonally  bounded  (DB)  arrays 
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as  in  band  arrays,  but  an  integer  designating  the  boundary  line.  See  Figure 
16.  The  s,  n',  and  w1  fields  serve,  as  in  band  ACBs,  to  determine  6D  and  <5R. 
Most  of  the  ACB  information  for  subarrays  is  copied  from  the  corre- 
sponding fields  of  the  parent  array  ACB.  For  subarrays  of  band  type,  A<i,i>, 
this  includes  A,  t,  n1,  w' .  The  y.  and  s  values  are  simple  functions  of  the 

partition  lines  and  the  corresponding  parent  field.  The  value  of  w  is 
IOC(A(s))  as  computed  by  the  formulas  of  the  previous  section.  The  width,  w, 
is  min(y.  of  subarray,  w  of  parent  array)  . 

With  the  exception  of  the  t,  to,  and  w  fields,  the  DB  subarray  ACB 
information  is  generated  in  the  same  manner  as  that  for  band  subarrays.  Given 
that  s,  the  (i,j)  coordinates  (with  respect  to  the  original  array)  of  the 
upper  left  corner  of  the  DB  subarray,  has  been  found,  t  is  determined  by  the 
rules: 

x  =  lower  DB  (LDB)   if  i  <  j 
t  =  upper  DB  (UDB)   if  i  >  j 

Next,  it  is  ascertained  whether  s  is  a  stored  element.  If  it  is,  then  to  can 
be  found.  For  UDB,  the  value  of  w  is  i-i'-l,  where  i1  is  the  largest  number 
greater  than  i  such  that  A(i',j)  is  a  stored  element.  Similarly,  for  LDB, 
w^j'-j+l.  If  s  is  not  a  stored  element,  then,  for  LDB,  that  i1  >  i  is  found 
such  that  A(i',j)  is  a  stored  element.  Then  w=LOC(A(i* , j) )  and  w=i-i*. 
Similarly,  for  UDB,  oy=LOC(A(i,  j ') )  and  w=j'-j.  This  procedure  may  be  applied 
to  any  non-band  subarray,  null  subarrays  being  discovered  when  the  "nearest" 
stored  element  lies  outside  the  bounds  of  the  subarray. 

The  partitioning  of  subarrays  of  band  type  follows  the  same  pro- 
cedure as  that  for  the  original  band  array.  For  DB  subarrays,  where  arbitrary 
row  and  column  partitioning  is  allowable,  all  subarrays  are  assumed  to  be  the 
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Figure  16.  Values  of  w  for  boundary  lines 
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same  type  as  the  parent  with  null  subarrays  being  found  by  the  same  procedure 
as  outlined  above. 

3.3  Discussion  of  Arithmetic  and  "Part  of"  Operations 

The  sum  or  product  of  a  band  or  DB  matrix,  and  another  matrix  re- 
sults in  a  matrix  whose  type  is  dependent  upon  n  and  w  (using  either  interpre- 
tation) .  In  the  present  system,  this  necessitates  defaulting  the  type  of  the 
result  to  rectangular.  This  action  is  in  contradiction  to  the  philosophy  of 
not  storing  theoretically  zero  elements.  It  is  not  known  whether  functions 
can  be  found  to  determine  the  desired  array  type  of  the  result  from  the  type, 
n,  and  w  of  the  operands. 

The  feature  of  taking  "part  of"  has  not  been  fully  investigated  for 
tend  arrays.  The  triangular  "part  of"  a  band  array  may  be  considered  as  a  DB 
subarray  and  be  represented  as  such.  The  band  "part  of"  a  band  array  can  be 
implemented  due  to  the  n,  w,  n',  and  w1  fields.  This  would  include  taking  the 
diagonal  and  tridiagonal  "part  of"  since  both  of  these  arrays  are  band  arrays 
in  the  general  sense.  The  band  "part  of"  an  array  whose  6D=1,  0  or  -1  may  be 
implemented  by  making  the  band  part  seem  as  if  it  were  in  a  subarray  of  a 
larger  band  array  where  5D  would  have  the  same  value. 
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4.   ROTATE  OPERATOR 

4.1  Introduction 

In  an  array  language  it  is  desirable  to  have  many  different  geo- 
metric array  types.  This  feature  of  a  programming  language  allows  great 
flexibility  for  the  user  in  the  approach  of  his  problem.  To  have  too  few 
array  types  may  make  it  necessary  for  the  user  to  complicate  or  obscure  the 
logic  of  his  program  by  building  "unusual"  arrays  from  smaller  available 
types.  In  the  worst  case,  he  may  have  to  change  algorithms.  Such  restric- 
tions defeat  the  purpose  of  an  array  language. 

One  approach  to  the  addition  of  new  geometric  array  types  is  to 
define  them  explicitly.  This  is  a  major  task  involving  finding  ACB  fields 
which  adequately  and  efficiently  represent  the  new  types.  Some  of  the  arrays 
desired  do  not  have  a  constant  6D,  and  problems  similar  to  those  of  band 
arrays  arise.  Origin  calculation  equations  and  representations  of  subarrays 
must  be  found.  In  effect,  one  must  start  anew  for  each  array  type  to  be  added. 

Another  consideration  is  that  of  the  size  and  complexity  of  the 
compiler  tables  which  describe  the  operations  of  addition,  multiplication, 
taking  "part  of",  etc.,  on  ordered  pairs  of  array  types.  For  example,  the 
geometric  type  of  the  product  of  a  tridiagonal  matrix  and  a  lower  triangular 

matrix  is  required  in  the  ACB  of  the  temporary  matrix  which  holds  the  result. 

2 

For  n  array  types,  each  of  these  tables  is  on  the  order  of  n  .  To  double  the 

number  of  array  types,  which  is  the  intent,  would  increase  the  size  of  each 
table  by  a  factor  of  four. 

From  the  above  considerations,  it  becomes  clear  that  another  approach 
should  be  considered.  In  the  next  section,  we  will  consider  the  use  of  a  re- 
sult from  group  theory  to  simplify  the  problem  of  implementing  additional 
geometric  array  types. 
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4.2  The  Dy  Group 

In  this  approach,  the  new  array  types  are  not  defined  explicitly, 
but  are  generated  from  existing  ones.  All  of  the  information  regarding  array 
representation  by  ACB  nodes  and  PCB  nodes,  however,  remains  the  same. 

The  basis  for  this  approach  lies  in  the  dihedral  group  of  order 
four,  D^.  This  group  has  a  geometric  analog  in  the  rotations  of  a  square  [4]. 

See  Figure  17.  The  elements  of  D^^  consist  of  a,  b,  c,  and  d,  rotations  in 

space  about  axes  of  symmetry;  e,  f ,  and  g,  clockwise  rotations  of  90  ,  180  , 
and  270°,  respectively,  about  the  square's  center  in  its  plane;  and  h,  the 
identity,  no  rotation.  From  the  algebraic  point  of  view,  new  array  types 
could  be  obtained  by  operating  on  an  available  array  type  with  an  element  or 
combination  (product)  of  elements  in  D.. 

One  need  not  implement  all  the  elements  of  D^,  explicitly.  Savings 

are  made  by  implementing  a  subset  of  D^^  and  generating  the  other  elements  by 

taking  products  of  elements  in  this  subset.  While  certain  pairs  of  elements 
in  D.  will  generate  the  whole  group,  i.e.,  {a,c},  the  subset  {a,b,c}  was 

chosen  for  ease  and  simplicity  of  implementation  of  the  remaining  elements. 
From  the  group  table  and  the  following  equations,  the  elements  of 
Du  are  shown  to  be  generated  by  a,  b,  and  c. 

a  =  a 
b  =  b 
c  =  c 
d  =  a*b*c 
e  =  b*c 
f  =  a-b 
g  =  a«c 
h  =  a«a 
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Figure  17.  Rotations  of  a  square  -  the  dihedral  group,  D. 
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Since  D.  is  not  Abelian,  these  operators  mast  be  applied  to  an  array  from  left 

to  right: 

(d)(A)  =  (a.b-c)(A)  =  (b.c)(a(A))  =  (c)(b(a(A))) 

This  fact  is  crucial  in  the  implementation. 

The  set  of  array  types  resulting  from  operating  on  the  current  array 
types  with  elements  of  D^.  may  be  divided  into  two  classes.  One  class  consists 

of  arrays  of  the  same  type  as  those  available  previously,  but  with  the  elements 
rearranged  within  the  general  shape.  This  class  may  be  characterized  by  1) 
symmetry  with  respect  to  the  main  diagonal,  or  2)  a  boundary  line  parallel  to 
the  main  diagonal.  The  other  class  consists  of  the  new  array  types.  These 
arrays  are  characterized  by  1)  symmetry  with  respect  to  the  backward  main  di- 
agonal, where  the  backward  main  diagonal  is  that  line  passing  through  the  upper 
right  and  lower  left  corners  of  the  array,  or  2)  a  boundary  line  parallel  to 
the  backward  main  diagonal. 

4.3  Implementation 

4.3.1  Backward  Diagonal  Array 

From  the  previous  discussion,  the  construction  of  new  array  types 
involves  only  the  implementation  of  the  elements  a,  b,  and  c  of  D..  Trans- 
position, c,  is  already  implemented.  This  leaves  a  and  b,  column  and  row  re- 
versal, respectively.  These  operations  can  be  implemented  with  the  use  of  a 
backward  diagonal  array.  See  Figure  18.  A  backward  diagonal  array  is  the 
identity  array  with  the  rows  (or  columns)  reversed.  Column  reversal  of  a 
array,  A,  is  accomplished  in  theory  by  post-multiplying  A  by  a  backward  di- 
agonal matrix  of  order  m,  where  m  is  the  number  of  columns  in  A.  Row  reversal, 
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Figure  18.     Backward  diagonal  array 


32 

similarly,  is  accomplished  in  theory  by  pre-multiplying  A  by  a  backward  di- 
agonal matrix  of  order  n,  where  n  is  the  number  of  rows  in  A.  Because  of  the 
special  form  of  backward  diagonal  arrays,  these  multiplications  may  be  imple- 
mented with  special  techniques.  Notice  also  that  the  transpose  of  a  backward 
diagonal  array  is  also  a  backward  diagonal  array.  This  fact  leads  to  sore 
simplification.  An  example  for  a  3x3  upper  triangular  array  is  given  in 
Figure  19. 

Thus,  the  syntax  for  the  rotate  operator  could  be  (A,  < integer >) 
where  <integer>  describes  how  the  array  A  is  to  be  rotated,  i.e.,  which  ele- 
ment of  D,  is  to  be  applied  to  A.  The  compiler  could  then  replace  this  term 

with  the  appropriate  equivalent  expression  in  terms  of  A,  backward  diagonal 
arrays,  and  the  transpose  operator.  Since  the  dimensions  of  A  are  dynamic, 
the  dimensions  of  the  backward  diagonal  arrays  cannot  be  set  until  execution 
time. 

4.3.2  Setting  of  Bits  in  CALL  Statement 

The  inplementation  of  the  transpose  operator  in  the  current  version 
of  OL/2  is  done  by  means  of  flags.  An  addition,  multiplication,  or  assignment 
operation  results  in  a  call  to  a  subroutine  to  carry  out  the  desired  task. 
Some  of  the  parameters  in  the  argument  list  of  the  subroutine  are  flags  indi- 
cating whether  their  associated  arrays  are  to  be  transposed  before  operating 
with  than.  A  simplified  example  is: 

CALL  MULT(A,0,B,1,C); 

T 
which  forms  A*B  and  assigns  the  result  to  C.  The  flag  indicates  how  the  ele- 
ments of  its  corresponding  array  are  to  be  accessed.  The  elements  are  not 
physically  transposed.  A  flag  value  of  1  designates  that  element  A(i,j)  of  the 
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124        |    x    |         1         |=|        4  2    |  (EDxA)'   =  A'xED' 

I    3  5  6    I         11  I         |    6  5  3    |  =  A'xED 


ED  A  ED 


f  =  a»b 
11        11231        I  11        |6  |  180°  rotation 


I  1        |    x    |        4  5    |    x    |        1        |   =    |    5  4        |  EDxAxED 

II  II  6||1  |         |321| 


13  5  6   1  270°  rotation 

=    12  4        |  (AxED)1   =  ED'xA" 

I    1  I  =  EDxA' 


Figure  19.     Eackward  diagonal  method  applied  to  UT  3x3  array 
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transposed  matrix  is  actually  stored  in  location  A(j,i)  of  the  original 
array. 

Both  row  reversal  and  column  reversal  can  be  implemented  in  a 
similar  manner.  Let  there  be  two  more  flags  associated  with  each  array  in  a 
CALL  statement.  These  flags  are  then  used  to  indicate  whether  the  array's 
rows  or  columns,  or  both,  are  to  be  reversed  before  operating  with  it.  Again 
the  elements  would  not  be  physically  moved.  For  row  reversal,  element  A(i,j) 
of  the  new  array  is  actually  located  in  A(n-i+l,j)  of  the  original  array. 
Similarly,  for  column  reversal,  A(i, j)  is  actually  in  A(i,m-j+l) ,  where  the 
original  array  is  mxn.  Combinations  of  these  twD  flags  and  the  transpose 
flag  exhaust  all  the  elements  of  LV.  Note  again  that  because  LV  is  not 

Abelian,  a,  b,  and  c  must  be  used,  when  applicable,  in  precisely  that  order. 

This  second  approach  seems  much  more  appealing.  No  multiplications 
need  be  performed.  In  the  backward  diagonal  array  method,  the  result  of  the 
rotation  must  be  stored  in  a  rectangular  temporary  matrix  and  any  further 
operations  must  use  the  zeros  which  are  generated,  whereas  in  the  second  meth- 
od no  additional  storage  is  required  and  computational  efficiency  is  retained. 
Finally,  because  of  the  similarity  of  the  second  method  to  the  already  imple- 
mented transpose  operator,  little  additional  program  logic  is  required  for  its 
implementation . 
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5.  CONCLUSION 

The  preceding  sections  have  shown  the  feasibility  of  adding  Hes- 
senburg  and  band  arrays,  and  a  rotate  operator  to  the  OL/2  language.  Most, 
if  not  all,  of  the  necessary  information  for  the  implementation  of  Hessen- 
burg  arrays  has  been  given  and  such  implementation  should  therefore  be 
straightforward.  The  same  optimism  is  felt  for  the  realization  of  the  ro- 
tate operator,  due  to  its  similarity  with  the  already  implemented  transpose 
operator.  The  implementation  of  band  arrays,  on  the  other  hand,  is  expected 
to  present  some  problems,  caused  in  most  part  by  the  new  ACB  representation. 
All  in  all,  with  the  inclusion  of  these  new  features,  the  user  of  the  01/2 
language  will  hopefully  find  a  shorter  and  easier  path  to  the  solution  of 
his  problems. 
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